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DETAILED ACTION 

1 . A request for continued examination under 37 CFR 1 .1 14, including tlie fee set fortli in 37 CFR 
1.17(e), was filed in this application after final rejection. Since this application is eligible for 
continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been 
timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 
1.114. 

2. The following is a non-final action in response to applicant's amendment and response 
5/25/2010, responding to the 2/25/2010 office action provided in rejection of claims 1-8 and 10- 
21. Claims 1, 3, 5, 12, 14, and 16 have been amended. Claims 1-8 and 10-21 are pending and 
are addressed in this office action. New grounds of rejection are presented in view of the newly 
presented limitation(s). 



Response to Arguments 

3. Applicant's arguments filed5/25/201 0 in particular pages 12-17, have been fully considered. 

4. With respect to the objection to the drawings, the amendments to the drawings overcome these 
objections and they are withdrawn. 

5. With respect to the obviousness-type double patenting rejection, a terminal disclaimer was filed 
on 5/25/2010. The rejection is withdrawn. 

6. With respect to the previous rejection of the claims under 35 USC 112, second paragraph, the 
amendments to the claims overcome this rejection and it is withdrawn. The amendments to the 
claims give rise to new issues under 35 USC 112, and new rejections are presented herein. 

7. With respect to the rejection of claims under 35 USC 103(a), the amendments to the 
independent claims (1 and 16) overcome the rejections presented in the previous Office Action. 
New rejections are presented herein. Applicant's arguments have been considered but are moot 
in view of the new ground(s) of rejection. 
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Response to Amendment 

8. Applicant's amendment to tfie claims filed 5/25/2010 present substantial new limitations, which 

raises the issue of new matter under 25 USC 112, first paragraph. Examiner is not readily able to 
find support for each of the new limitations in the specification as amended or as originally filed. 
Applicant is requested to point out where in the specification each new limitation finds support, in 
order to avoid the issue of new matter under 25 USC 112, first paragraph. 

Specification 

9. The amendment to the specification filed 5/25/201 0 has been entered. 

10. The amendment to the specification filed 11/25/2009 has been entered because it finds support 
at least in the original claims. Examiner interprets further references to an "actual" 
implementation in the specification to be equivalent to the definition module and its class (such as 
"the actual implementation of the provider class" (page 2 lines 15-16), "the implementation" (page 
2 line 30) and "implementation class description" (page 3 lines 25-26)). This interpretation is 
consistent with the amendments to the specification as filed. 

11. The original specification filed 3/31/2005 was published as pre-grant publication US 
2006/0248538 A1 . The original specification was amended by Applicant at the time of filing on 
3/31/2005, and further amended on 1/25/2009. 

1 2. The specification is accepted as amended. 



13. 



Drawings 

Original drawing 1 was received on March 31 , 2005. Amended drawing 1 and new drawing 2 
were received on 5/25/2010. The drawings are accepted. 
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Claim Rejections - 35 USC § 112 

14. The following is a quotation of the first paragraph of 35 U.S.C. 112: 

The specification shall contain a written description of the invention, and of the manner and process of 
making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the 
art to which it pertains, or with which it is most nearly connected, to make and use the same and shall 
set forth the best mode contemplated by the inventor of carrying out his invention. 

15. Claims 1-8 and 10-21 are rejected under 35 U.S.C. 112, first paragraph, as failing to comply with 
the written description requirement. The claims contain subject matter which was not described 
in the original specification, filed 3/31/2005, in such a way as to reasonably convey to one skilled 
in the relevant art that the inventor(s), at the time the application was filed, had possession of the 
claimed invention. 

16. Claim 1 has been amended to recite "determining whether the interface includes an additional 
method that is called during runtime execution of the computer program" (lines 18-19). The 
Examiner is unable to find support for this limitation in the portion of the specification cited by 
Applicant (page 2, line 17 through page 3 lines 4, and page 4 lines 22-28, as noted in Applicant's 

remarks filed 5/25/2010, page 12). There is no description of an interface including an additional 
method that is called during runtime execution in the disclosure as filed, nor does the 
specification reasonably convey or suggest that the interface includes such a method. Instead, 
the closest description of this limitation in the specification is on page 2, lines 28-31: "if an 
interface promises the availability of a certain method but the method is not present in the 
implementation, a customer of that method would fail at latest at run time." Under the principles 
of compact prosecution, examiner treats this limitation as pertaining to the interface includes a 
method that is not present in the implementation (specification, page 2 lines 28-31 ). 



17. Claim 12 recites a similar limitation and is rejected for the same reasons. Claims 2-9, 10-11, and 
13-21 are rejected because they depend from rejected claims. 
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18. Claim 3 has been amended to recite "the class having the object is converted into a new class" 
(lines 2-3). Applicant notes that support for the new amendments may be found in page 2, line 1 7 
through page 3 lines 4 and page 4 lines 22-28 of the original specification (Applicant's remarks 
filed 5/25/2010, page 12). However, there is no description of a "new class" the disclosure as 
filed, nor does the specification reasonably convey that the interface should include such 
conversion of one class into another new class. Under the principles of compact prosecution, 
examiner treats this limitation as identical to claim 3 as originally filed. The Examiner 
understands the original claim 3 to be described in the specification at page 4 lines 4-10, 
particularly: "the generation of executable programs in script languages, such as for example 
JavaScript is done by first generating an intermediate code, using a language that supports 
classes and interfaces." 

19. Claim 14 recites a similar limitation and is rejected for the same reasons. Claims 4, 5, 15, and 16 
are rejected because they depend from rejected claims. 

20. The following is a quotation of the second paragraph of 35 U.S.C. 112: 

The specification shall conclude with one or more claims particularly pointing out and distinctly 
claiming the subject matter which the applicant regards as his invention. 

21. As noted in a prior Office Action, in view of the amended specification paragraphs received 
11/25/2009, the Examiner interprets further references to an "actual" implementation in the 
specification, such as "the actual implementation of the provider class" (page 2 lines 15-16), "the 
implementation" (page 2 line 30) and "implementation class description" (page 3 lines 25-26) to 
be equivalent to the definition instructions and its class. This interpretation is consistent with the 
amendments to the specification as filed. 

22. Claims 1 -8 and 1 0-21 are rejected under 35 U.S.C. 1 1 2, second paragraph, as being indefinite for 
failing to particularly point out and distinctly claim the subject matter which applicant regards as 
the invention. 
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23. Claim 1 includes "a class having an object with a runtime function" (lines 5-6) and "a provider 
class" (lines 7-8). Claim 1 further recites "the class" in line 16 and in line 17. The limitation "the 
class" is indefinite because it is unclear which "class" in the computer program is intended to be 
further described by the limitations of lines 16 and 17. Examiner is able to find support for 
"determining whether the object is relying on a feature of the provider class that is not promised 
by the provider class" (specification, page 2 lines 1 1 -14). Examiner is unable to find support for 
the alternate interpretation in the specification. Under the principles of compact prosecution, 
examiner treats the limitation as being equivalent to the supported limitation. 

24. Claim 12 recites a similar limitation and is rejected for the same reasons. Claims 2-9, 10-11, and 
13-21 are rejected because they depend from rejected claims. 

Claim Rejections - 35 USC § 103 

25. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all obviousness 
rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as 
set forth in section 102 of this title, if the differences between the subject matter sought to be 
patented and the prior art are such that the subject matter as a whole would have been obvious 
at the time the invention was made to a person having ordinary skill in the art to which said 
subject matter pertains. Patentability shall not be negatived by the manner in which the invention 
was made. 

26. Claims 1 -8 and 1 0-21 are rejected under 35 U.S.C. 103(a) as being unpatentable over "Java and 
XML Data Binding" (McLaughlin, 2002) in view of "The Java Language Specification, Second 
Edition" (Gosling et al., 2000) and in view of Lucas et al. (US 6,754,884 B1). 

27. Newly added amendments to the claims are underlined to aid the reader. 
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Claim 1 

McLaughlin teaches a computer-implemented method for validating computer code (see 
at least section 3.1.4, Figure 3-1 validating Binding schema against DTD). McLaughlin further 
teaches the method being executed by a computer {see at least page 13, sidebar 1, "at runtime"). 

McLaughlin further teaches providing a computer program by defining at least one set of 
definition instructions ("binding schema") and at least one set of implementation instructions 
("constraint model") (see at least section 3.1). McLaughlin further teaches the set of definition 
instructions ("binding schema") includes a class having an object with a runtime function (see at 
least section 3.3, particularly: "Once you've got your constraints ... you're ready to create a 
binding schema for your classes. This will instruct the class generation tool to generate classes, 
to use a specific Java package, to use collections, and a variety of other options.", example 3-4 
"Modified binding schema for movies database", particularly, "type='class'" and "The result of this 
addition is apparent in the Movies class, which has multiple Movie subobjects"). McLaughlin 
further teaches the set of implementation instructions ("constraint model") includes an interface 
("element") having a method ("attribute", "ATTLIST") (see at least section 3.2, "Creating the 
constraints", particularly "a set of constraints ready to generate classes from" and example 3-1 
"ELEMENT movies" and "ATTLIST movies version"). McLaughlin further teaches the class 
having the obiect is associated with a provider class (see at least section 3.3, particularly "The 
result of this addition is apparent in the Movies class, which has multiple Movie subobjects"). The 
object ("Movie subobjects") is relying on features of a provider class (Movie class). 

McLaughlin further teaches validating the set of definition instructions ("XML document") 
and the set of implementation instructions ("constraint model") (see at least section 3.1.1, 
particularly "ensure that your constraint model syntax is supported by the binding framework you 
want to use" and "Write several XML documents ... and validate them against your new 
constraints.") McLaughlin further teaches validating by determining whether the class is in 
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compliance with the interface (see at least section 3.4.3 "Verifying Output", particularly: "To 
ensure that the generated classes work, all you need to do is ensure that they compile"). 
Applicant teaches that the final validation is done through a compiler in at least page 4 lines 4-34, 
particularly: "The validity of these interfaces and classes is then proved using methods as 
described above, i.e. using a compiler that performs the usage and implementation checks at the 
semantics level." McLaughlin also teaches validating before runtime and during compilation, in at 
least figure 3-1 , pages 13 and 14 "Class generation process flow", particularly "Java compiler." 

McLaughlin further teaches determining whether the method of the interface can be used 
to execute the runtime function when the object is called during runtime execution of the 
computer program (see at least section 3.4.3 "Verifying Output", particularly: "To ensure that the 
generated classes work, all you need to do is ensure that they compile"). Applicant teaches that 
the final validation is done through a compiler in at least page 4 lines 4-34, particularly: "The 
validity of these interfaces and classes is then proved using methods as described above, i.e. 
using a compiler that performs the usage and implementation checks at the semantics level." 
McLaughlin also teaches validating before runtime and during compilation, in at least figure 3-1 , 
pages 13 and 14 "Class generation process flow", particularly "Java compiler." 

McLaughlin teaches a standard Java compiler to validate implementation and definition 
instructions. McLaughlin does not explicitly teach that the compiler checks the class for features 
or the interface for methods. However, Gosling teaches a standard Java compiler determining 

whether the obiect in a first class is relying on a feature of a provider class that is not promised by 
the class (see at least page 347, particularly: "If the class or interface has no method declaration 
that is both applicable and accessible, then a compile-time error occurs."). 

Gosling further teaches determining whether the interface includes an additional method 
that is called during runtime execution of the computer program (see at least page 199: An 
interface declaration introduces a new reference type whose members are classes, interfaces. 
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constants and abstract methods. " emphasis added). As noted in the above rejection under 35 
DSC 112, first paragraph, under the principles of compact prosecution, examiner treats this 
limitation as pertaining to the interface promising multiple methods that may be called by a 
computer program during run time, as is well known in the art of computer programming and 
partially supported by the cited portion of the specification (page 2 lines 28-31). 

Gosling further teaches verifying whether implementation of the provider class is in 
compliance with a promise of the provider class, the verification being performed bv using the 
interface (see at least pages 230, section 12.1.2= and 233-236, section 12.3, "Linking of Classes 
and Interfaces," particularly: "Verification of the binary representation" and "Verification ensures 
that the binary representation of a class or interface is structurally correct." and "that every 
method is provided with a structurally correct signature"). The signature of a method in an 
interface or class is a promise of that interface or class. 

It would have been obvious to one of ordinary skill in the art at the time the invention was 
made that the standard Java compiler verifications as suggested by McLaughlin include the 
verification features taught by Gosling because the "Java Language Specification" describes the 
Java language (Gosling page xix, "This book attempts a complete specification of the syntax and 
semantics of the language."). 

McLaughlin further teaches wherein the determination is made before runtime execution 
of the computer program and during compilation of the computer program (see at least figure 3-1 , 
pages 13 and 14 "Class generation process flow", particularly "Java compiler"). 

McLaughlin further teaches a computer program comprises other web services (see at 
least section 1.2.2, particularly "web services"). However, the combination of McLaughlin and 
Gosling does not explicitly teach a script code section. Lucas teaches a script code section (see 
at least column 3, lines 45-55, particularly "XML-oriented language extensions for use in 
association with a scripting language"). 
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Lucas further teaches generating a symbol table based on the script code section, the 
symbol table including a variable used bv the script code section (see at least figures 3A to 3C 
and associated text such as 3:58 through 4:7, particularly: "a Javascript-aware parser (e.g. parser 
105) is equipped to recognize XML data type declarations and associate them with the 
appropriate items in the corresponding symbol table"). The association of a variable with an item 
in the respective symbol table indicates that the symbol table was generated. 

Lucas further teaches validating the script code ("JavaScript") section bv comoarina the 
symbol table with the set of implementation instructions ("XML data type declarations") (see at 
least figures 3A to 3C and associated text such as column 3, line 56 through column 4 line 7, 
particularly: "a JavaScript-aware parser (e.g. parser 105) is equipped to recognize XML data type 
declarations and associate them with the appropriate items in the corresponding symbol table"). 

It would have been obvious to one of ordinary skill in the art at the time the invention was 
made to combine the constraint model of McLaughlin with the script code validation of Lucas 
because it would allow XML constraints to be used and tested with a script-based web service 
(see at least McLaughlin section 1 .2.2 and Lucas column 3 lines 45-55). 

Claim 2 

Claim 2 includes all of the limitations of claim 1 . Applicant states in page 3 lines 6-26 that 
their program is programmed using two separate tree structures, written in XML, wherein the first 
tree structure represents the classes to be implemented (definition module) and the second tree 
structure represents the associated interfaces (implementation module). McLaughlin further 
teaches the set of definition instructions are definition modules (see at least section 2.3.1 , 
particularly "XML file" and figure 2-2 "XML documents"). McLaughlin further teaches definition 
modules having a plurality of classes (see at least section 3.3, particularly: "Once you've got your 
constraints ... you're ready to create a binding schema for your classes . This will instruct the 
class generation tool to generate classes, to use a specific Java package, to use collections, and 
a variety of other options." emphasis added). 
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McLaughlin furtlier teaclies the set of implementation instructions are implementation 
modules (see at least section 2.3, particularly "XML constraints" and section 6.4.4 "Interfaces, 
particularly: "To generate an interface, add this statement to your binding schema"). McLaughlin 
further teaches implementation modules having a pluralitv of interfaces (see at least section 3.2, 
"Creating the constraints", particularly "a set of constraints ready to generate classes from" and 
example 3-1 "ELEMENT movies" and "ATTLIST movies version"). Because XML constraints are 
a model of the behavior of classes ("XML document"), they are an interface, as supported by 
specification page 3 lines 6-26. 

Claim 3 

Claim 3 includes all of the limitations of claim 1 . Claim 3 has been amended to recite "the 
class having the object is converted into a new class." As noted in the rejection of claim 3 under 
35 use 112, first paragraph for lack of written description, under the principles of compact 
prosecution, examiner treats this limitation as identical to claim 3 as originally filed. The 
Examiner understands the original claim 3 to be described in the specification at page 4 lines 4- 
10, particularly: "the generation of executable programs in script languages, such as for example 
JavaScript is done by first generating an intermediate code, using a language that supports 
classes and interfaces." 

McLaughlin further teaches the set of definition instructions are converted into classes 
(see at least section 3.1.4, figure 3-1 "Class generation process flow" and "The result of the 
generation step is one or more Java source files"). 

McLaughlin further teaches the set of implementation instructions are converted into 
interfaces (see at least section 6.4.4 "Interfaces", particularly "The result of this statement is a 
new generated class, the Person interface"). 
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Claims 4, 6, 10, and 11 

Claim 4 includes all of the limitations of claim 3. Claims 6, 1 0 and 1 1 include the 
limitations of claim 1 . IVIcLaughlin further teaches the set of definition instructions ("XML 
documents") and tiie set of implementation instructions ("XML constraints") are described in XML 
(see at least section 2.3.1 , particularly "XML file" and figure 2-2 "XML documents" and section 
2.3, particularly "XML constraints"). It is readily apparent that McLaughlin teaches the files are in 
a tree structure because the files are XML files. 

Claim 5 

Claim 5 includes all of the limitations of claim 4. McLaughlin further teaches tfie class 
having the object and the interface having the method are defined in Java language (see at least 
section 3.1 .4, figure 3-1 , particularly: "The result of the generation step is one or more Java 
source files"). 

Claim 7 

Claim 7 includes all of the limitations of claim 1 . IVIcLaughlin further teaches a computer 
program comprises other web services (see at least section 1.2.2, particularly "web services"). 
However, McLaughlin does not explicitly teach a script code section. Lucas teaches the script 
code section is JavaScript (see at least column 3, lines 45-55, particularly "a scripting language, 
such as JavaScript"). It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to combine the constraint model of McLaughlin with the JavaScript script 
code validation of Lucas because it would allow XML constraints to be used and tested with a 
script-based web service (see at least McLaughlin section 1 .2.2 and Lucas column 3 lines 45-55). 

Claim 8 

Claim 8 includes all of the limitations of claim 1 . McLaughlin further teaches validating 
the script code section comprises generating a symbol table by executing the code section in an 
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interpreter ("parser"), and comparing the symbol table with the implementation instruction ("XML 
data type declarations") (see at least column 3, line 56 through column 4 line 7, particularly: "a 
JavaScript-aware parser (e.g. parser 105) is equipped to recognize XIVIL data type declarations 
and associate tinem mVn the appropriate items in tine corresponding symbol table"). It would have 
been obvious to one of ordinary skill in the art at the time the invention was made to combine the 
constraint model of McLaughlin with the script code validation of Lucas because it would allow 
validating a script-based web service with XML constraints (see at least McLaughlin section 1 .2.2 
and Lucas column 3 lines 45-55). 

Claims 12-21 

Claims 12-21 are a computer readable medium version, which otherwise recites the 
same limitations of the claims 1-8 and 10-11. The combination of McLaughlin and Lucas teaches 
all of the limitations of claims 1 -8 and 10-11. It is readily apparent that the method taught by 
McLaughlin includes instructions to implement the method on a computer readable medium (see, 
for example, section 3.1 step 4, "compile the classes"). 
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Cited Prior Art 

28. Hammerich et al. (US PG-PUB 2004/0123273 A1, hereafter '273) was cited in tlie Office Action 
mailed 8/28/2009 as claiming priority to the same European application (EP 02022042.2). 
Hammerich et al. (US 7,584,457) was cited in the Office Action mailed 8/28/2009 as being a 

granted patent from application '273. 

29. Examiner's Note: The Examiner has pointed out particular references contained in the prior art 
of record within the body of this action for the convenience of the Applicant. Although the 
specified citations are representative of the teachings in the art and are applied to the specific 
limitations within the individual claim, other passages and figures may apply. Applicant, in 
preparing the response, should consider fully the entire reference as potentially teaching all or 
part of the claimed invention, as well as the context of the passage as taught by the prior art or 
disclosed by the Examiner. 
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Conclusion 

20. Any inquiry of a general nature or relating to the status of this application or concerning this 
communication or earlier communications from the Examiner should be directed to Erika 
Kretzmer whose telephone number is (571) 270-5554. The Examiner can normally be reached 
Monday through Thursday, 9:30am-6:00pm Eastern Time. If attempts to reach the examiner are 
unsuccessful, the Examiner's supervisor, Tuan Dam can be reached at (571) 272-3695. 

21 . Information regarding the status of an application may be obtained from the Patent Application 
Information Retrieval (PAIR) system. Status information for published applications may be 
obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR system, 
see http://portal.u3pto.gov/external/portai/paii . Please direct questions on access to the Private 
PAIR system to the Electronic Business Center (EBC) at 866.217.9197 (toll-free). 

22. Any response to this action should be mailed to: 

Commissioner of Patents and Trademarks 

Washington, D.C. 20231 
or faxed to 571-273-8300. Hand delivered responses should be brought to the United States 
Patent and Trademark Office Customer Service Window: 

Randolph Building 

401 Dulany Street 

Alexandria, VA 22314. 



/Erika Kretzmer/ 
Examiner, Art Unit 21 92 
2/8/201 1 



/Michael J. Yigdall/ 

Primary Examiner, Art Unit 2192 



